Read enough MES vendor roadmaps from the last two release cycles and you’ll notice the vocabulary shift before you notice anything else. “Copilot” is fading. “Agent” is everywhere. That’s not a marketing refresh — it describes a real change in what the software is allowed to do. A copilot drafts a recommendation and a human clicks approve. An agent evaluates conditions, decides, and writes the transaction. Same underlying models, in many cases, but a very different relationship to your system of record.
The problem is that most plants haven’t updated their procedures to match. Teams are still running change control, training, and incident response as if every AI feature on the floor requires a human to press a button. Increasingly, that assumption is false, and the gap between how the software actually behaves and how the plant governs it is where the real risk lives.
What “agentic” actually means when it hits your MES
Strip away the branding and agentic capability in an MES context usually means the software has been given standing permission to execute one or more of these actions without a per-instance human approval:
- Auto-adjusting the production schedule — re-sequencing work orders in response to a machine down event, a material shortage, or a quality hold, without a scheduler reviewing the new sequence first.
- Auto-closing work orders — declaring a work order complete based on quantity confirmations, scan data, or inferred completion signals, rather than an operator or supervisor signing off.
- Auto-triggering quality holds — quarantining a lot or a genealogy chain based on a statistical or model-driven anomaly detection, before a quality engineer has looked at the data.
- Auto-generating and dispatching work instructions or routing changes based on real-time context (an operator’s certification status, an equipment fault code, an SPC trend).
Each of these used to be a recommendation surfaced in a dashboard. In 2026 releases from several major MES and manufacturing-cloud vendors, they’re increasingly framed as things the agent “handles” by default, with human review positioned as an optional guardrail you configure — not a step baked into the workflow.
That inversion is the whole story. It’s the difference between AI that makes your team faster at decisions they still own, and AI that makes decisions your team merely reviews afterward, or not at all.
Where the audit trail actually breaks
MES has spent two decades building credibility around traceability — ISA-95 hierarchies, genealogy, electronic batch records, 21 CFR Part 11 style signature chains where required. That credibility rests on a simple premise: every state change has an accountable human or a deterministic rule behind it. Agentic AI strains that premise in a few specific, recognizable ways.
The decision isn’t reproducible. A rule engine that closes a work order because “quantity confirmed equals quantity ordered” is auditable in the traditional sense — you can point to the rule. An LLM-influenced agent that weighs sensor trends, historical patterns, and natural-language context to make a judgment call isn’t reliably reproducible from the same inputs, and vendors are often unable (or unwilling) to fully expose the reasoning path. “The agent decided” is not an audit finding a quality auditor or an FDA investigator will accept as an explanation.
The signature moves, but the accountability doesn’t follow it. Plenty of MES platforms now let the agent’s action get logged under a system account or a service identity rather than a named person. That satisfies a data-logging requirement. It does not satisfy an accountability requirement, and in regulated industries it may not satisfy your quality system at all.
Escalation paths are quietly optional. Vendors will tell you the agent can be configured to require human-in-the-loop approval for high-risk actions. True, usually. But “can be configured” is doing a lot of work in that sentence. Default configurations, especially in early releases, tend to favor autonomy because that’s the feature being sold. Plants that don’t explicitly lock down thresholds are accepting whatever the vendor’s default risk tolerance happens to be.
Downstream systems don’t know an agent made the call. ERP, WMS, and quality systems receiving a transaction from your MES generally can’t distinguish “operator confirmed” from “agent inferred.” If the agent’s judgment was wrong, the error propagates through every integrated system before anyone questions the source.
A pilot checklist before an agent gets write access
None of this means agentic features are a bad idea — auto-triggering a quality hold on a real anomaly faster than a human would catch it is genuinely valuable. It means the decision to let an agent write to your MES deserves the same rigor you’d apply to any other change to a validated or business-critical system. Before you move a pilot past sandbox mode, require the following:
- A documented action inventory. Get the vendor to list, explicitly, every write action the agent is capable of performing, not just the ones marketed. If they can’t produce this list cleanly, that’s your answer.
- Reversibility for every autonomous action. Can a schedule change, a work order closure, or a hold be rolled back cleanly, with the rollback itself logged? If an action can’t be undone without manual reconciliation, it shouldn’t run unattended.
- A named accountable role, not a system account. Every autonomous action should log to a human owner of that agent’s configuration — the person who set the thresholds and who answers for them in an audit, not a generic “AI-agent” identity.
- Tiered autonomy by risk class. Low-risk, easily reversible actions (re-sequencing a queue) are a different category from high-risk, hard-to-reverse ones (closing a genealogy-linked work order, releasing a hold). Insist on separate approval thresholds for each tier, not one global on/off switch.
- Explainability at the transaction level. The agent should be able to state, in plain terms attached to the transaction record, what inputs and thresholds drove the decision. “Model confidence 0.87” is not an explanation a plant manager or auditor can act on.
- A kill switch that’s actually fast. Test, during the pilot, how long it takes to disable autonomous write access plant-wide or per-line. If it requires a vendor support ticket, that’s a governance failure waiting to happen.
- A defined incident response path specific to agent error — not your generic IT incident process, but one that addresses mis-scheduled orders, wrongly closed work orders, or false-negative holds, with a clear owner for containment and correction.
The procedural work is the actual project
The engineering lift of turning on an agentic feature is often small — a config flag, a permission set, maybe an integration test. The organizational lift of deciding who’s accountable when it acts wrong is the real project, and it’s the one plants are skipping because it doesn’t show up on a vendor’s feature list.
Treat the shift from copilot to agent as what it is: a change to who — or what — holds write authority over your system of record. That’s worth a change-control review on its own, independent of whatever quarter your vendor happens to be launching it in.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
